home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf-IIb.43 / doc / review / p4 < prev    next >
Encoding:
Text File  |  1986-02-01  |  3.7 KB  |  84 lines
  1. .SH
  2. Submit
  3. .PP
  4. For all the changes to its internals, the external interface of
  5. \fBsubmit\fR has changed remarkably little since MMDFI.
  6. The only notable external changes to \fBsubmit\fR are that it now
  7. processes domain-style addresses (both forward and reverse!)
  8. and both RFC822
  9. and RFC733 format addresses.
  10. .FN
  11. D. Crocker, J. Vittal, K. Pogran, D. Henderson, ``RFC733 - Standard
  12. for the Format of ARPA Network Text Message'',
  13. Network Information Center, SRI International, November 1977.
  14.  
  15. D. Crocker, ``RFC822 - Standard
  16. for the Format of ARPA Network Text Message'',
  17. Network Information Center, SRI International, August 1982.
  18. .FE
  19. A couple of new options have been added to \fBsubmit\fR to give some
  20. control over the handling of returned mail in the event that a message
  21. cannot be delivered.  This is
  22. useful if the user is a program and does not care if
  23. the message is undeliverable!
  24. It is also now possible to feed a bare message to \fBsubmit\fR and tell
  25. \fBsubmit\fR to find all the addresses and show them and their validity
  26. on a one-by-one basis.  This makes it convenient
  27. to feed mail to \fBsubmit\fR from a smart mail composer that doesn't want to
  28. know how to parse addresses (a major task these days!).
  29. .PP
  30. The \fBsubmit\fR program can operate in one of two modes.
  31. In \fIprotocol\fR mode, \fBsubmit\fR accepts options, a return address,
  32. and optionally a list of addresses for each message, followed by the
  33. message text.  Multiple messages can be submitted
  34. one after another without reinvoking the \fBsubmit\fR process.
  35. Each address is individually acknowledged.  If there is an error,
  36. the submission of that letter is aborted and a new submission
  37. may be made.
  38. In \fIone-shot\fR mode a single message is submitted on the standard
  39. input.
  40. As in \fIprotocol\fR mode, it can be preceded by options and addresses,
  41. or the options can be given on the command line and the addresses taken
  42. from the message text.
  43. .PP
  44. The internal address verification process of \fBsubmit\fR has changed
  45. greatly since MMDFI.  Most of the changes
  46. have been made to properly support domain style addresses.
  47. Additional changes were made to support per-channel
  48. and per-user access
  49. controls.
  50. While \fBsubmit\fR is checking each address, regardless
  51. of origin, it is also compiling the address
  52. list for the message.
  53. Each address list entry contains the destination domain,
  54. .FN
  55. By ``domain'' we mean the full domain specification of a host, e.g.
  56. VAX1.UDEL.ARPA.
  57. .FE
  58. the destination mailbox,
  59. and the channel in whose channel table \fBsubmit\fR first found the destination
  60. host.
  61. The lookup is somewhat complicated.
  62. The destination domain is looked up in the domain tables;
  63. the first entry found is used.
  64. Each domain table entry has associated with it the routing to be used to reach
  65. that domain/host.  Normally this is just the name of the host itself
  66. if the host is directly accessible, but it can be a sequence of hosts if the
  67. destination is not directly accessible.
  68. This ``routing host'' is then looked up in the channel tables
  69. to find a channel which can reach it.  The routing host specifications
  70. and the entries in the channel tables are always full domain specifications,
  71. so as to be unambiguous.
  72. .PP
  73. Authorization is checked after a valid channel for a host is found.
  74. Access to send via a given channel
  75. depends on the originating channel and/or the submitting user.
  76. If access to a given channel is denied, \fBsubmit\fR will continue to look
  77. at subsequent channels to see if some other channel has access to the
  78. same host and is authorized.  This mechanism is commonly used
  79. to restrict access to expensive transport systems or to restrict
  80. message transfer between channels representing private and public
  81. data networks.
  82. It can also be used to restrict relaying of messages between two
  83. "controlled-access" networks.
  84.